Discovery procedures are required to discover addresses or other configuration parameters of data sources or servers for providing services to a terminal device or client. According to the Dynamic Host Configuration Protocol (DHCP), as specified in the Internet Engineering Task Force Request For Comments (IETF RFC) 2608, a dynamic allocation of network addresses is defined, where temporary or permanent network (IP) addresses are allocated to hosts. The basic mechanism for the dynamic allocation of network addresses is simple. A client requests the use of an address for some period of time. The allocation mechanism guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. To achieve this, the client broadcasts a DHCP discover message which is passed on to DHCP servers not on the same physical subnet. Each server may then respond with a DHCP offer message that includes an available network address and/or other configuration parameters. The client receives one or more DHCP offer messages from one or more servers and may choose one server from which to request configuration parameters, based on the configuration parameters offered in the received DHCP offer messages. Then, the client broadcasts a DHCP request message including the server identifier to indicate which server it has selected, such that those servers not selected by the DHCP request message may use the message as a notification that the client has declined that servers offer. The server selected in the DHCP request message commits the binding for the client to persistent storage and response with a DHCP acknowledge message containing the configuration parameters for the requesting client.
According to the Domain Name Server (DNS) protocol specification as defined e.g. in the IETF RFC 1035, domain names are used as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus, a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. The resolver is responsible for hiding the distribution of data among name servers from the user. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information. In return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant data bases in other servers.
Previously, the internet server systems and thus also their configuration parameters (e.g. addresses) have been quite stable and they have been configured manually based on user specific settings to the terminal. However, in the case of wireless Internet, for example WLANs (Wireless Local Area Networks), the configuration using DHCP and DNS protocols does not take into consideration wide area cellular type rapid mobility. In particular, a mobile station or mobile terminal may send a DHCP query in order to find an IP address of a P-CSCF (Proxy Call State Control Function) or some other service lookup server. The DHCP server in the network answers with a P-CSCF address. Then, the mobile terminal contacts the P-CSCF in order to get a list of available multimedia services. The P-CSCF can take into account the type of network to which it is contacted, so that not all of the services designed for the PS (Packet-Switched) domain may technically be possible in the CS (Circuit-Switched) domain for example because of the low capacity of the CS network. The P-CSCF answers with a list of services which are now available to the user.
In mobile Internet, the dynamic configuration of the configuration parameters (e.g. server addresses) should be adapted to the movements of the mobile terminal. Solutions for such a dynamic service configuration are provided by the Service Location Protocol (SLP) specified in the ITEF RFC 2608, which provides a scalable framework for discovery and selection of network services. A user agent which is a process working on the users behalf to establish contact with some service by retrieving service information from service agents or directory agents performs discovery by issuing service request messages. Furthermore, a Service Discovery Protocol (SDP) is specified in the Bluetooth Specification Version 1.0 B issued on 29. November 1999 by the Bluetooth Forum, where a service discovery mechanism is provided as a means for client applications to discover the existence of services provided by server applications as well as the attributes of those services. The attributes or configuration parameters of a service include the type or class of service offered and the mechanism or protocol information needed to utilize the service. A set of SDP server available to an SDP client can change dynamically based on the RF (Radio Frequency) proximity of the servers to the client. When a server becomes available, a potential client must be notified that the client can use SDP to query the server about its services. Similarly, when a server leaves proximity or becomes unavailable for any reason, the client may use SDP to poll the server and may infer that the server is not available if it no longer response to requests.
However, these known dynamic service configuration procedures do not provide an automatic server address configuration or reconfiguration procedure and a service configuration customization mechanism.
When a mobile terminal moves across the radio, network and service area coverage, it is a problem for the user to manually configure server or proxy server addresses. In practice, it is almost impossible to configure the addresses manually, because the user cannot be aware of the current service configuration of the operator. This is especially true when localized area specific servers of a visited operator are considered. For example, a user is abroad and wants to find out special offers of local restaurants and the like. Thus, an automatic and operator specific service configuration is highly desirable.